I did some internet sloothing and found they plan to remove completely [1] [2]
) and recommend to just use third party extension. I made that change in my suggestion in package.json. It also removed deprecation warning

Maybe just update this now to call lint:check:js and lint:check:css so lint:check dosen't run lint:css twice

Sorry I think this was supposed to be lint:js-check.

I think you rid of this later anyways. so i'm ignoring

yeah it turn out that no changes are needed in the workflow file after the scripts are simplified

I guess the parallel might be slightly more convenient, but maybe could cause issues if the linters touch the same files? If they don't, im okay with it. If they do, maybe just use sequential to be safer

the linters touch the same files

Supposedly no at the moment. ESLint would only look into js, jsx, ts, and tsx files and we're asking Stylelint to look only into css files.

okay ltgm

I think you rid of this later anyways. so i'm ignoring

I'm happy to do this or just use the string formatter... I dont mind looking at logs

Sure. I think we can add the problem matcher for the string formatter in another PR soon.

Before I make the changes let's take a look at the approaches we can take:

1. Use a custom formatter in Stylelint and a custom action in the GitHub workflow.
   PROS: We can view the errors in a nicely formatted way and we can have the errors annotated inline by GitHub.
   CONS: setting up custom stuff takes time; we might not want to use custom stuff given they might not always be compatible with the tooling upgrades / GitHub workflow, which means we might not want to maintain it as a long term solution.
2. Use the default string formatter.
   PROS: It's the default formatter which means it should have the best support from the tooling contributors.
   CONS: We lose the ability to have the errors annotated inline (until we move the files into the project root). It outputs relative paths, but GitHub workflow problem matchers only resolves paths from the project root. Supposedly we can check in the problem matcher, which currently does nothing, in the same PR to save another PR, but it's hard to verify if things would actually work. If we spot any issues after we move the log-viewer files, we might still need to fix in the PR we move the files or another PR.
3. Use the github formatter.
   PROS: We don't need any custom plugin to get the GitHub annotation working.
   CONS: We will see a deprecated warning in the workflow results. We're using a deprecated but not yet removed formatter. If we don't upgrade the Stylelint version the formatter should still be there, and it's less likely we would upgrade it before we move the new-log-viewer files and migrate to the problem matcher approach.

I still think Approach 3 gives us the most benefits, but all CONs are minor since we might always need another PR to improve the lint experience after we move the new-log-viewer files.

Okay i think it dosen't matter so much as we are going to move soon anyways. I am okay with 3.
Do you like this by any chance? This way we still preserve normal formatting when running locally (i.e. run lint:check locally and lint:ci for workflow)

"lint:ci": "npm-run-all --sequential --continue-on-error lint:check:js \"lint:check:css -- --formatter github\""

you would need to modify workflow to use lint:ci